🦋 Changeset detected

Latest commit: 7368c91

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Preview: https://svelte-dev-git-preview-kit-14744-svelte.vercel.app/

What would this look like in practice?

<script>
import { form } from "$lib/remote/forms.remote.ts";
import { schema } from "$lib/schema";

function validate() {
  form.preflight(schema).validate({ preflightOnly: true }); // runs preflight schema
  form.validate(); // runs server schema
}
</script>

<form {...form}></form>

or

<script>
import { form } from "$lib/remote/forms.remote.ts";
import { schema } from "$lib/schema";

function validate() {
  form.validate(); // runs preflight schema
  form.validate({ preflightOnly: false }); // skips preflight, runs server schema
}
</script>

<form {...form.preflight(schema)}></form>

The preflight schema would always be used. This just allows you to skip server validation. So you could for example do preflight validation on every keystroke, but additionally run server validation on change events (which are emitted when you blur an input you've been typing into, etc):

<form
  {...myform.preflight(schema)}
  oninput={() => myform.validate({ preflightOnly: true })}
  onchange={() => myform.validate()}
>...</form>

One thing I don't love about this is that server issues get nuked as soon as preflight-only validation succeeds. We can fix that with a simple change...

-const is_server_validation = !validated?.issues;
+const is_server_validation = !validated?.issues && !preflightOnly;

...but then we have another problem: preflight validation issues will be added to server validation issues, instead of replacing them, and it looks really weird.

Fixing that is slightly trickier. I've opened #14759 to address it.

I don't sure I understand - I do want to have the server validation issues persisted when a preflight validation fails. Why wouldn't I? There's no world in which a server validation can be duplicate to a preflight validation, because then the server validation wouldn't have ran in the first place. Having a server validation issue ripped out under my fingers while typing is never a good thing IMO. And IIRC we agreed that we don't want to have them go away, so the simple fix should be enough?

Consider a case similar to the one in the test case I added in #14759 — on the server you have this schema...

v.object({
	a: v.pipe(v.string(), v.minLength(3, 'a is too short'), v.maxLength(7, 'a is too long')),
	b: v.pipe(v.string(), v.minLength(3, 'b is too short')),
	c: v.pipe(v.string(), v.minLength(3, 'c is too short'))
})

...and on the client you have this:

v.object({
	a: v.pipe(v.string(), v.maxLength(7, 'a is too long')),
	b: v.string(),
	c: v.string()
})

This is contrived, but totally valid — the preflight constraints are a subset of the server-side constraints. If you submit this with empty inputs, preflight validation will succeed and you'll be left with the following:

a is too short
b is too short
c is too short

Currently on this branch, as soon as you start typing into the a input, all those issues get nuked. With the simple change, they don't get nuked, but as soon as I violate the preflight constraint, I end up in this absurd situation:

a is too short
b is too short
c is too short
a is too long

a cannot possibly be both too short and too long. Granted this is a contrived situation, and in many cases could be resolved by making the preflight constraints match the server-side constraints more closely, but to me it indicates that we do need to get rid of server issues if we have newer preflight issues.